Elements for Data Link Layer Traffic Measurement

Data Type: unsigned8 Data Type Semantics: identifier ElementId: 413 References: [IEEE802.1Q] Status: current Range: The valid range is 0-7. 3.2.7. dot1qCustomerSourceMacAddress Description: The value of the Encapsulated Customer Source Address (C-SA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q]. Abstract Data Type: macAddress Data Type Semantics: default ElementId: 414 References: [IEEE802.1Q] Status: current 3.2.8. dot1qCustomerDestinationMacAddress Description: The value of the Encapsulated Customer Destination Address (C-DA) portion of the Backbone Service Instance Tag (I-TAG) Tag Control Information (TCI) field of an Ethernet frame as described in [IEEE802.1Q]. Abstract Data Type: macAddress Data Type Semantics: default ElementId: 415 Kashima, et al. Standards Track [Page 15] RFC 7133 Data Link Layer Information Elements May 2014 References: [IEEE802.1Q] Status: current 3.2.9. postL2OctetDeltaCount Description: The definition of this Information Element is identical to the definition of the layer2OctetDeltaCount Information Element, except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. This Information Element is the layer 2 version of postOctetDeltaCount (ElementId #23). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 417 References: [RFC5477] Status: current Units: octets 3.2.10. postMCastL2OctetDeltaCount Description: The number of layer 2 octets since the previous report (if any) in outgoing multicast packets sent for packets of this Flow by a multicast daemon within the Observation Domain. This property cannot necessarily be observed at the Observation Point but may be retrieved by other means. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of postMCastOctetDeltaCount (ElementId #20). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 418 Kashima, et al. Standards Track [Page 16] RFC 7133 Data Link Layer Information Elements May 2014 References: [RFC5477] Status: current Units: octets 3.2.11. postL2OctetTotalCount Description: The definition of this Information Element is identical to the definition of the layer2OctetTotalCount Information Element, except that it reports a potentially modified value caused by a middlebox function after the packet passed the Observation Point. This Information Element is the layer 2 version of postOctetTotalCount (ElementId #171). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 420 References: [RFC5477] Status: current Units: octets 3.2.12. postMCastL2OctetTotalCount Description: The total number of layer 2 octets in outgoing multicast packets sent for packets of this Flow by a multicast daemon in the Observation Domain since the Metering Process (re-)initialization. This property cannot necessarily be observed at the Observation Point but may be retrieved by other means. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of postMCastOctetTotalCount (ElementId #175). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter Kashima, et al. Standards Track [Page 17] RFC 7133 Data Link Layer Information Elements May 2014 ElementId: 421 References: [RFC5477] Status: current Units: octets 3.2.13. minimumL2TotalLength Description: Layer 2 length of the smallest packet observed for this Flow. The packet length includes the length of the layer 2 header(s) and the length of the layer 2 payload. This Information Element is the layer 2 version of minimumIpTotalLength (ElementId #25). Abstract Data Type: unsigned64 ElementId: 422 References: [RFC5477] Status: current Units: octets 3.2.14. maximumL2TotalLength Description: Layer 2 length of the largest packet observed for this Flow. The packet length includes the length of the layer 2 header(s) and the length of the layer 2 payload. This Information Element is the layer 2 version of maximumIpTotalLength (ElementId #26). Abstract Data Type: unsigned64 ElementId: 423 References: [RFC5477] Kashima, et al. Standards Track [Page 18] RFC 7133 Data Link Layer Information Elements May 2014 Status: current Units: octets 3.2.15. droppedL2OctetDeltaCount Description: The number of layer 2 octets since the previous report (if any) in packets of this Flow dropped by packet treatment. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of droppedOctetDeltaCount (ElementId #132). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 424 References: [RFC5477] Status: current Units: octets 3.2.16. droppedL2OctetTotalCount Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that were dropped by packet treatment since the (re-)initialization of the Metering Process. This Information Element is the layer 2 version of droppedOctetTotalCount (ElementId #134). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 425 References: [RFC5477] Kashima, et al. Standards Track [Page 19] RFC 7133 Data Link Layer Information Elements May 2014 Status: current Units: octets 3.2.17. ignoredL2OctetTotalCount Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process. This Information Element is the layer 2 version of ignoredOctetTotalCount (ElementId #165). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 426 References: [RFC5477] Status: current Units: octets 3.2.18. notSentL2OctetTotalCount Description: The total number of octets in observed layer 2 packets (including the layer 2 header) that the Metering Process did not process since the (re-)initialization of the Metering Process. This Information Element is the layer 2 version of notSentOctetTotalCount (ElementId #168). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 427 References: [RFC5477] Kashima, et al. Standards Track [Page 20] RFC 7133 Data Link Layer Information Elements May 2014 Status: current Units: octets 3.2.19. layer2OctetDeltaSumOfSquares Description: The sum of the squared numbers of layer 2 octets per incoming packet since the previous report (if any) for this Flow at the Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetDeltaSumOfSquares (ElementId #198). Abstract Data Type: unsigned64 Data Type Semantics: deltaCounter ElementId: 428 References: [RFC5477] Status: current Units: octets 3.2.20. layer2OctetTotalSumOfSquares Description: The total sum of the squared numbers of layer 2 octets in incoming packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. The number of octets includes layer 2 header(s) and layer 2 payload. This Information Element is the layer 2 version of octetTotalSumOfSquares (ElementId #199). Abstract Data Type: unsigned64 Data Type Semantics: totalCounter ElementId: 429 References: [RFC5477] Kashima, et al. Standards Track [Page 21] RFC 7133 Data Link Layer Information Elements May 2014 Status: current Units: octets 4. Modification of Existing Information Elements Related to Packet Section The new Information Elements related to packet section (i.e., sectionOffset and sectionExportedOctets) can be applied to not only dataLinkFrameSection but also to all kinds of packet section (i.e., ipHeaderPacketSection, ipPayloadPacketSection, mplsLabelStackSection, and mplsPayloadPacketSection defined in [RFC5477]). Therefore, existing Information Elements Descriptions should be modified as follows. 4.1. ipHeaderPacketSection This Information Element is defined in [RFC5477]. The description has been updated from [RFC5477]. Description: This Information Element carries a series of n octets from the IP header of a sampled packet, starting sectionOffset octets into the IP header. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP header. With sufficient length, this element also reports octets from the IP payload. However, full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804]. The sectionExportedOctets expresses how much data was exported, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Kashima, et al. Standards Track [Page 22] RFC 7133 Data Link Layer Information Elements May 2014 Abstract Data Type: octetArray ElementId: 313 References: [RFC2804] [RFC5477] Status: current 4.2. ipPayloadPacketSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: This Information Element carries a series of n octets from the IP payload of a sampled packet, starting sectionOffset octets into the IP payload. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP payload. The IPv4 payload is that part of the packet that follows the IPv4 header and any options, which [RFC0791] refers to as "data" or "data octets". For example, see the examples in [RFC0791], Appendix A. The IPv6 payload is the rest of the packet following the 40-octet IPv6 header. Note that any extension headers present are considered part of the payload. See [RFC2460] for the IPv6 specification. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol.Data Type: octetArray ElementId: 313 References: [RFC2804] [RFC5477] Status: current 4.2. ipPayloadPacketSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: This Information Element carries a series of n octets from the IP payload of a sampled packet, starting sectionOffset octets into the IP payload. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP payload. The IPv4 payload is that part of the packet that follows the IPv4 header and any options, which [RFC0791] refers to as "data" or "data octets". For example, see the examples in [RFC0791], Appendix A. The IPv6 payload is the rest of the packet following the 40-octet IPv6 header. Note that any extension headers present are considered part of the payload. See [RFC2460] for the IPv6 specification. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Kashima, et al. Standards Track [Page 23] RFC 7133 Data Link Layer Information Elements May 2014 Abstract Data Type: octetArray ElementId: 314 References: [RFC0791] [RFC2460] Status: current 4.3. mplsLabelStackSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: This Information Element carries a series of n octets from the MPLS label stack of a sampled packet, starting sectionOffset octets into the MPLS label stack. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the head of the MPLS label stack. With sufficient length, this element also reports octets from the MPLS payload. However, full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804]. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol.Data Type: octetArray ElementId: 314 References: [RFC0791] [RFC2460] Status: current 4.3. mplsLabelStackSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: This Information Element carries a series of n octets from the MPLS label stack of a sampled packet, starting sectionOffset octets into the MPLS label stack. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the head of the MPLS label stack. With sufficient length, this element also reports octets from the MPLS payload. However, full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804]. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Kashima, et al. Standards Track [Page 24] RFC 7133 Data Link Layer Information Elements May 2014 Abstract Data Type: octetArray ElementId: 316 References: [RFC2804] [RFC3031] [RFC3032] [RFC5477] Status: current 4.4. mplsPayloadPacketSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: The mplsPayloadPacketSection carries a series of n octets from the MPLS payload of a sampled packet, starting sectionOffset octets into the MPLS payload, as it is data that follows immediately after the MPLS label stack. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the MPLS payload. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Abstract Data Type: octetArray ElementId: 317Data Type: octetArray ElementId: 316 References: [RFC2804] [RFC3031] [RFC3032] [RFC5477] Status: current 4.4. mplsPayloadPacketSection This Information Element is defined in [RFC5477]. The description is updated from [RFC5477]. Description: The mplsPayloadPacketSection carries a series of n octets from the MPLS payload of a sampled packet, starting sectionOffset octets into the MPLS payload, as it is data that follows immediately after the MPLS label stack. However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the MPLS payload. See [RFC3031] for the specification of MPLS packets. See [RFC3032] for the specification of the MPLS label stack. The sectionExportedOctets expresses how much data was observed, while the remainder is padding. When the sectionExportedOctets field corresponding to this Information Element exists, this Information Element MAY have a fixed length and MAY be padded, or it MAY have a variable length. When the sectionExportedOctets field corresponding to this Information Element does not exist, this Information Element SHOULD have a variable length and MUST NOT be padded. In this case, the size of the exported section may be constrained due to limitations in the IPFIX protocol. Abstract Data Type: octetArray ElementId: 317 Kashima, et al. Standards Track [Page 25] RFC 7133 Data Link Layer Information Elements May 2014 References: [RFC3031] [RFC3032] Status: current 5. Modification of Existing Information Elements Related to VLAN Tag The traffic measurement using IPFIX and PSAMP for a Provider Backbone Bridged Network requires the Information Elements related to Backbone Service Instance Tag (I-TAG) and Backbone VLAN Tag (B-TAG). The set of Information Elements related to I-TAG is added in Section 3, because I-TAG structure and semantics are different from that of Service VLAN Tag (S-TAG) and Customer VLAN Tag (C-TAG). The set of Information Elements related to B-TAG reuses the existing Information Elements, because B-TAG structure and semantics are identical to that of C-TAG and S-TAG. This section modifies existing descriptions and references related to C-TAG and S-TAG as follows. 5.1. dot1qVlanId Description: The value of the 12-bit VLAN Identifier portion of the Tag Control Information field of an Ethernet frame. The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q]. In Provider Bridged Networks, it represents the Service VLAN identifier in the Service VLAN Tag (S-TAG) Tag Control Information (TCI) field or the Customer VLAN identifier in the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q]. In Provider Backbone Bridged Networks, it represents the Backbone VLAN identifier in the Backbone VLAN Tag (B-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q]. In a virtual link between a host system and EVB bridge, it represents the Service VLAN identifier indicating S-channel as described in [IEEE802.1Qbg]. In the case of a multi-tagged frame, it represents the outer tag’s VLAN identifier, except for I-TAG. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 243 Status: current References: [IEEE802.1Q] [IEEE802.1Qbg] Kashima, et al. Standards Track [Page 26] RFC 7133 Data Link Layer Information Elements May 2014 5.2. dot1qPriority Description: The value of the 3-bit User Priority portion of the Tag Control Information field of an Ethernet frame. The structure and semantics within the Tag Control Information field are defined in [IEEE802.1Q]. In the case of a multi-tagged frame, it represents the 3-bit Priority Code Point (PCP) portion of the outer tag’s Tag Control Information (TCI) field as described in [IEEE802.1Q], except for I-TAG. Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 244 Status: current References: [IEEE802.1Q] 5.3. dot1qCustomerVlanId Description: The value represents the Customer VLAN identifier in the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q]. Abstract Data Type: unsigned16 Data Type Semantics: identifier ElementId: 245 Status: current References: [IEEE802.1Q] 5.4. dot1qCustomerPriority Description: The value represents the 3-bit Priority Code Point (PCP) portion of the Customer VLAN Tag (C-TAG) Tag Control Information (TCI) field as described in [IEEE802.1Q]. Kashima, et al. Standards Track [Page 27] RFC 7133 Data Link Layer Information Elements May 2014 Abstract Data Type: unsigned8 Data Type Semantics: identifier ElementId: 246 Status: current References: [IEEE802.1Q] 6. The Relationship between Ethernet Header Fields and Information Elements The following figures show a summary of various Ethernet header fields and the Informational Elements that would be used to represent each of the fields. <-6 --> <-6 --> <-4 --> <---2 ----> +---------+---------+---------+-------------+ | | | | | | C-DA | C-SA | C-TAG | Length/Type | | a | b | c | d | +---------+---------+---------+-------------+ a.(Information Element) destinationMacAddress (80) b.(Information Element) sourceMacAddress (56) c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) d.(Information Element) ethernetType (256) Figure 1: Customer-Tagged Frame Header FieldsData Type: unsigned8 Data Type Semantics: identifier ElementId: 246 Status: current References: [IEEE802.1Q] 6. The Relationship between Ethernet Header Fields and Information Elements The following figures show a summary of various Ethernet header fields and the Informational Elements that would be used to represent each of the fields. <-6 --> <-6 --> <-4 --> <---2 ----> +---------+---------+---------+-------------+ | | | | | | C-DA | C-SA | C-TAG | Length/Type | | a | b | c | d | +---------+---------+---------+-------------+ a.(Information Element) destinationMacAddress (80) b.(Information Element) sourceMacAddress (56) c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) d.(Information Element) ethernetType (256) Figure 1: Customer-Tagged Frame Header Fields <-6 --> <-6 --> <-4 --> <-4 --> <---2 ----> +---------+---------+---------+---------+-------------+ | | | | | | | C-DA | C-SA | S-TAG | C-TAG | Length/Type | | a | b | c | d | e | +---------+---------+---------+---------+-------------+ a.(Information Element) destinationMacAddress (80) b.(Information Element) sourceMacAddress (56) c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) d.(Information Elements) dot1qCustomerVlanId (245), dot1qCustomerPriority (246) e.(Information Element) ethernetType (256) Figure 2: Service-Tagged Frame Header Fields Kashima, et al. Standards Track [Page 28] RFC 7133 Data Link Layer Information Elements May 2014 <-6 --> <-6 --> <-4 --> <--16 ---> <-4 --> <---2 ----> +---------+---------+---------+------------+---------+-------------+ | | | | | | | | B-DA | B-SA | B-TAG | I-TAG | C-TAG | Length/Type | | a | b | c | d | e | f | +---------+---------+---------+------------+---------+-------------+ a.(Information Element) destinationMacAddress (80) b.(Information Element) sourceMacAddress (56) c.(Information Elements) dot1qVlanId (243), dot1qPriority (244) d.(Information Elements) dot1qServiceInstanceTag (411), or a set of dot1qServiceInstanceId (412), dot1qServiceInstancePriority (413), dot1qCustomerSourceMacAddress (414) dot1qCustomerDestinationMacAddress (415), e.(Information Elements) dot1qCustomerVlanId (245), dot1qCustomerPriority (246) f.(Information Element) ethernetType (256) Figure 3: Backbone-VLAN-Tagged Frame Header Fields 7. Security Considerations Reporting more granular data may increase the risk of DoS attacks against a Collector. Protection against DoS attacks is discussed in Section 11.4 of [RFC7011]. The recommendations in this document do not otherwise introduce any additional security issues beyond those already mentioned in [RFC7011] and [RFC5477]. 8. IANA Considerations Existing IPFIX Information Elements [IANA-IPFIX] have been modified as indicated in Sections 3.1, 4, and 5. Per Section 5.2 of [RFC7013], for each of these changes, [RFC7133] has been appended to the Requester in IANA’s IPFIX registry [IANA-IPFIX], the Information Element’s Revision number has been incremented by one, and the Information Element’s revision Date column has been updated. New IPFIX Information Elements [IANA-IPFIX] have been allocated as shown in Section 3.2. Kashima, et al. Standards Track [Page 29] RFC 7133Data Link Layer Information ElementsMay 2014 9. AcknowledgmentsThanks to Brian Trammell and the IPFIX working group participants whocontributed to mailing-list discussions throughout the development ofthis document. Special thanks to Pat Thaler for her help with theIEEE 802 aspects of this work.10. References10.1. Normative References[IEEE802.11] IEEE, "IEEE Standard for Information technology.Telecommunications and information exchange betweensystems Local and metropolitan area networks.Specific requirements Part 11: Wireless LAN MediumAccess Control (MAC) and Physical Layer (PHY)Specifications", IEEE Std 802.11-2012, March 2012.[IEEE802.1BR] IEEE, "IEEE Standard for Local and metropolitan areanetworks: Virtual Bridged Local Area Networks: BridgePort Extension", IEEE Std 802.1BR-2012, July 2012.[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan areanetworks: Media Access Control (MAC) Bridges andVirtual Bridged Local Area Networks", IEEE Std802.1Q-2011, August 2011.[IEEE802.1Qbg] IEEE, "IEEE Standard for Local and metropolitan areanetworks: Media Access Control (MAC) Bridges andVirtual Bridged Local Area Networks: Amendment 21:Edge Virtual Bridging", IEEE Std 802.1Qbg-2012, July2012.[IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std802.3-2012, December 2012.[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,September 1981.[RFC2119] Bradner, S., "